BigData-JAWS 勉強会#16 で「Lake House Architecture Pattern」というタイトルで発表してきました

データアナリティクス事業本部コンサルティングチームの石川です。3/1（月）BigData-JAWS 勉強会#16に参加してLake House Architectureについてお話をさせて頂きました。

Redshiftを導入しているお客様から、「今後データレイクを始めたい」というご要望をよく伺います。「データレイク」と聞くとGlue Crawlerでデータカタログに登録・更新、SparkでGlue ETLジョブ作成・実行が必要と考えられることが多いのですが、Redshiftをご利用であれば、SQLだけでデータレイクの構築・運用が可能です。

BigData-JAWS 勉強会#16

• BigData-JAWS 勉強会#16
  • 19:00 - 19:02　オープニング / OPTARC 丸本さん
  • 19:02 - 19:25 Lake House Architecture Pattern / クラスメソッド 石川
  • 19:25 - 19:48 AWSにおけるムービーレイクの運用 / サーバーワークス 田斉さん
  • 19:48 - 20:11 通信情報データ分析基盤整備PoCの振り返り / アイレット 大石さん
  • 20:11 - 20:24 Oracle x DMS x QuickSightでDBデータを可視化した話(がんばれQuickSight) / フォージビジョン 山口さん
  • 20:25 - 20:32 Athenaを使ったバッチ処理のTIPS / LT枠 Speee 香川さん
  • 20:32 - 20:40 とあるbig dataの等身大なあるある / LT枠 株式会社NTTデータ 野口達也さん
  • 20:40 - 21:00 re:Inventで発表されたBIGDATA関連技術 / AWS 下佐粉さん

Lake House Architecture

Lake House Architectureは、DWH（Redshift）からデータレイク（S3）や運用データベース（PostgreSQLやMySQL）のデータを統合して、分析することでより速くより深い洞察を得るためのアーキテクチャです。

更にRedshiftやAthenaから様々なデータソースにシームレスにアクセスできたり、データの移動なしにデータ共有できる仕組みも標準で提供されており、それを総称して、Lake House Architectureと呼んでいます。

Redshift Spectrum

S3データレイクにオープンフォーマットデータを直接クエリする

Data Lake Export

• S3データレイクにオープンフォーマットデータでエクスポートする
• Athena、EMR、Glue（Spark）、SageMakerにデータの連携する

Federated Query

• AWS環境のPostgreSQLやMySQLに直接クエリする

DWHのトレンドの変化

従来は、主にIT部門のデータエンジニアがデータの前処理やデータ分析を担っていましたが、現在ではビジネスユニットが業務ドメインを活かした分析することも一般化しました。いわゆる、データ分析の民主化がもたらした分析ニーズの変化です。

しかし、Redshiftがシェアードナッシングアーキテクチャの強みが活かせず、ストレージとコンピューティングの分離したアーキテクチャのほうが、ニーズにマッチしたアーキテクチャに

従来：トップダウンのデータ分析

• 企業のIT部門がトップダウンでデータ分析を主導
• データエンジニアがネストの深い分析クエリ作成、必要に応じてチューニング

現在：ボトムアップでセルフサービスBI

• ビジネスユニットがボトムアップでセルフサービスBI
• 業務ドメインを活かし、アドホックな結合や定型的な集計分析、チューニングレス

そこで登場したのが、ストレージとコンピューティングの分離したRA3インスタンスです。

データ分析サービスの進化

2017年のデータレイク関連サービスの登場をきっかけに、Redshiftからデータレイク（S3）や運用データベース（PostgreSQLやMySQL）のデータを統合する機能が拡充し、Redshiftとデータレイク間で相互にデータ連携できる仕組みが提供されました。今後、データの移動無しでRedshiftデータとデータレイクのシェアリングが可能になったり、Lake FormationのACIDトランザクションがサポートされる予定です。

2017年：データレイク関連サービスの登場

• Athena、Redshift Spectum、GlueのGA

2019年：RedshiftやData Lakeの進化

• Redshift Concurrency Scaling、RA3インスタンスのリリース、Lake FormationのGA

2020年：Lake House Architrecture

• Frederated Query関連サービス、データレイクのシェアリングのGA

2021年（予定）：Data SharingとData Lakeの進化

• Redshift AQUA、Redshift Dataのシェアリング、Lake Formation 3 Features、ML連携機能

イマドキのデータ分析基盤に求められる要件

これからのデータ分析基盤は、サイロ化したデータをコピーして統合するのではなく、DWHや運用DBの垣根なくデータの移動なしにデータを統合、統合したデータレイクをマルチクラウドで連携が可能になります。

• サイロ化したデータを統合して分析
  • データのゼロコピーでデータ統合したい
  • マルチクラウドでデータを共有したい
• BIツールによる可視化ワークロード
  • 企業BI：トップダウンで提供する定形ダッシュボードを多数のユーザーが利用
  • セルフサービスBI：ボトムアップでビジネス要件に応じてデータ探索

	企業BI	セルフサービスBI
部門	IT部門が主導	ビジネスユニットによって推進
重視	定型化、安定稼働	スピード、自由、創造性
アクセス特性	決まった曜日・時間などにアクセスが集中	アドホック

ETLワークロード

• CRMデータや基幹システムデータのロード、集計
• DWHからデータレイクへデータ共有
• DWHはただの最新データ置き場と化している

機械学習ワークロード

• データをファイルとして取り出すならデータレイクでファイルとして提供
• DBの強みを活かすなら、ML連携機能（RedshiftML、AthenaML）

Lake House Architecture Pattern

データレイク連携

これまでデータレイクのデータは、GlueやEMR上のSpark実行環境を用いてETLしていましたが、今後はRedshiftのSQLのみでELTした結果をデータレイクに提供できるようになり、データレイクのハードルが下がりました。

データのロード

Redshift Data API

IoT CoreからKinesis Firehose経由でS3にPUT、そのイベントでLambda Functionを起動してRedshiftにロードする場合、従来だとJDBCドライバ経由でRedshiftに接続してデータをロードしていました。Redshift Data APIを用いれば、JDBCドライバ準備不要、Redshiftにインバウンド接続なしでロードできるようになります。

SQLクライアント接続

データマート作成や分析用クエリは、従来通りODBC/JDBCドライバや接続クライアントを用いてSQLを実行するのが良いでしょう。

データのアンロード（Data Lake Export）

Data Lake Export + SQLによるデータレイクの構築

RedshiftのData Lake Exportを利用すると、Glue ETLジョブを使うことなくSQLだけでデータレイクが構築できます。S3に対してパーティションを指定やカラムナファイル（Parquet）出力も可能です。

データはスライスごとに出力されるので、必要に応じてPARALLEL OFF指定することで、パーティション内のファイルを１つのファイルにまとめることが可能です。

さらにRedshift Data APIを用いれば、AWSCLIからデータレイクを構築できます。

Concurrency ScalingによるUNLOADのスケーリング

RedshiftのUNLOADリクエストは、 Scaling ClusterにオフロードできるのでMain Clusterの負荷を気にせず、データレイクが構築できます。

Load less ELT(not ETL)

ロード不要なELT

Federated Query

Redshift Federated Query

Data Sharing

Lake Formation Cross account database sharing

データレイクのDBをクロスアカウントアクセスするさせる機能で、別のアカウントがデータレイクのDBをアクセスできるようにする。

Amazon Redshift data sharing（RA3のみ）

クラスタ間でデータのコピーや移動することなくデータを共有するサービスで、Amazon Redshiftクラスタ間でライブデータを素早くデータアクセスが可能になります。data sharingはデータへのライブアクセスを提供するため、データが更新されてもユーザーは常に最新の一貫性のある情報を見ることができます。

以下の例は、Redshift data sharingのアーキテクチャ例ですが、データレイクのシェアリングにおいても同様にデータの連携が可能になります。

最後に

• Lake House Architectureは、DWH（Redshift）からデータレイク（S3）や運用データベース（PostgreSQLやMySQL）のデータを統合して、分析することでより速くより深い洞察を得るためのアーキテクチャ
• データレイクといえば、Glue CrawlerやETLジョブと考えがちですが、Redshift SpectrumとData Lake Exportを用いれば、SQLのみでデータを加工し、Parquet出力可能です
• 今後、データレイクやRedshiftデータのシェアリングを通じて、さらにライブデータを統合、横断的な分析が可能になります

すでにRedshiftをご利用の方は、Lake House Architectureと、SQLだけでデータレイク構築をご検討いただければ幸いです。BigData-JAWS 勉強会に参加させていただきありがとうございました。